Date: Thu, 15 Jul 93 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #208
To: packet-radio
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Today's Topics:
                  HELP: Testing TCP/IP radio packets
                 How to supress nodes bcast in G8BPQ
                     MPF102 direct replacement ?
                            NOS and Baycom
                     Packet-Radio Digest V93 #207
                            RTTY DECODING

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Tue, 13 Jul 1993 21:22:12 GMT
From: lll-winken.llnl.gov!fastrac.llnl.gov!wsrcc.com!wetware!khijol!warrior!erc@ames.arpa
Subject: HELP: Testing TCP/IP radio packets
To: packet-radio@ucsd.edu

Andy Micone (andym@inrird.com) wrote:

: Besides, you wouldn't believe how many so-called military "experts" have
: told me lately "TCP/IP packets over radio, impossible!" ;)

I already replied to you via email, but perhaps this is something that can
be pass along to others.  If you put your TNC in transparent mode, you can
put pretty much whatever you like on top of AX.25 - uucp, slip, whatever.
It's not the most efficient, but it saves writing drivers and software,
and it easily interfaces with existing serial protocols.

I'm writing this on a 386 notebook computer, linked with a 486/25 via
two KPC-3 TNC's, an Icom P2AT HT and an Alinco DR-590 dual band radio.
Linked via uucp.
-- 
Ed Carp				erc@wetware.com			510/659-9560
   For anonymous mailers -->   anonymus+5300@charcoal.com
"Disagreements are not meant to be challenges.  They are just a different
 reality."  -- Risa D'Angeles

------------------------------

Date: 14 Jul 93 21:20:28 GMT
From: news-mail-gateway@ucsd.edu
Subject: How to supress nodes bcast in G8BPQ
To: packet-radio@ucsd.edu

In article <742404018snx@llondel.demon.co.uk> dave@llondel.demon.co.uk writes:
>>The only way you can do this is to set the route quality between the two
>>nodes to a low level. If you set the QUALITY to 10 and the MINQUAL to 10
>>then you should get a situation where the two nodes know about each other
>>but don't pass any other route info. You cn probably set both parameters
>>to a higher (but equal) level if you want both your nodes to propagate past
>>each other.
>>
>>Dave

kilroy!gwalsh@jpl.nasa.gov (Gerry) replies:
usc!elroy.jpl.nasa.gov!kilroy!gwalsh@

Hi Dave,
>
>That's what I thought.  One thing about the QUALITY parameter confuses
>me though.  Does G8BPQ "de-rate" the quality of each individual node (as
>provided by the broadcast from the node "up-stream") by a given amount?
>
>Lets say that some node sends out a NODES bcast and that a node called
>MTNTOP has a quality of 40 (as passed to my node in the bcast).  If my
>QUALITY parameter for that port is set to, say 70 will the MTNTOP node (when
>placed in *MY* nodes table) have a QUALITY of 70?  That would seem to
>defeat the purpose of bcasting a QUALITY.  My node should take the bcast
>quality of 40 and de-reate it to something like 30 or less, shouldn't
>it?
>
>The reason I ask is that I have tried (before using news) setting the
>QUALITY of the port to 50 and the MINQUAL to 20.  Only a *few* nodes
>made it through that filter.

Hi Gerry,

Let me quote to you out of the book:

"For each destination node listed in the broadcast, an indirect route
is assumed to exist via the node who originated the broadcast.

The quality of this route is calculated combining the BROADCAST QUALITY
with the CHANNEL QUALITY parameter appropriate to the channel over which
the broadcast was received.   The qualities are multiplied, normalized,
and rounded as shown in the following formula:"

Route Quality = (broadcast quality X channel quality + 128
                -------------------------------------------
                               256


Thus what quality a node has and whether it appears on your list is a
function of YOUR PORT quality and the quality your NEIGHBOR says it has
assigned for the node your NEIGHBOR IS HEARING!

A typical trick is to lower your PORT or HDLC quality to something around
say 112, and then have a MIN QUAL to BROADCAST of say 108.   This means that
all nodes you hear DIRECTLY will have a quality of 112.  The above formula
does not come into play until you start dealing with what your NEIGHBOR hears
and what of THAT you want to appear on your node list.

The answer here is to then LOCK (manually enter and end with a !) the route
quality to KNOWN GOOD NEIGHBORS!

Now what defines a "known good neighbor".  Is it that you have a solid radio
link to the guy?  Yes.. that's true, or should be true, but it is not the
end-all, do-all that the book tries to imply.  Another consideration is
DO YOU TRUST THE LIST THAT YOUR NEIGHBOR SAYS IT CAN GET TO?????  This is
the most IMPORTANT factor in assigning a manual route quality to a neighbor
node!

I.E.  Let's say that you had a PORT (or HDLC) QUALITY of 112, and a MINQUAL
to BROADCAST of 108, but then you MANUALLY entered a route quality to your
neighbor of 192!  This would in effect cause a lot of the nodes that your
neighbor HEARD to appear on YOUR list, and not only that, what your
NEIGHBORS NEIGHBOR HEARD TOO!  By twiddling this manual ROUTE QUALITY for
the specific neighbor node UP and DOWN in value, (while leaving PORT QUAL
set low) you can then adjust whether you want to hear just what your
neighbor is hearing DIRECT or what your neighbors NEIGHBOR hears too!

The good thing is that by doing this, you will not pass on nodes that you
hear during a bandopening!  Remember, all the nodes you hear then will have
the PORT (HDLC) quality of 112 and although they WILL be broadcast, your
neighbor node sysop has a WIDE variation on what you have told him is
"known good" and what you just happened to hear because the band was open.
This is known as "route locking" and is the best way to go about setting
up node automatic adaptive routing.

It prevents your node from using a path to a node that was heard on a
band opening, rather than a node that you know works ALL the time!

Twiddling with the default PORT (HDLC) QUALITY and MIN TO BROADCAST (also
sometimes called MIN TO UPDATE.. as in..... "appear on your node list")
affects EVERY NODE BROADCAST HEARD.  Pick a starting point and then
adjust your MANUAL route assignments to get what you want.

Remember, as long as your node has a PORT (HDLC) QUALITY higher than your
MIN to UPDATE, then it WILL send a node broadcast including all those
nodes!  Where you set the numbers to will influence whether your neighbor
LISTS them, but not whether you BROADCAST them!

If you want to limit BROADCAST SIZE, then simply have a PORT (HDLC) QUALITY
*LOWER* than MINQUAL!  This will stop your node from passing on ANY info
it hears from ANYONE else except it's own identity.  If you want to pass
on known good routes only.. do the above and then simply MANUALLY lock the
ROUTE QUALITY of SPECIFIC NEIGHBORS to a HIGHER number than MINQUAL!

This method will stop BROADCASTS of ALL band opening nodes.. they will
not appear on your node list, and they will not be broadcast to your
neighbors.  Pretty drastic action though.

Remember, ROUTE LOCKING is *NOT* the same as *NODE LOCKING*.  If you
manually lock a route quality, it will not broadcast the existence of
that node should it go away.. if you have locked the route quality and
your neighbor node bites the dust, your node will know it, will not route
to it, and will not broadcast its existence.

Judging from what appears on most node lists, the above is the least
understood aspect of a node by most sysops... it is confusing but once
you lower PORT QUAL and MINQUAL and then manually LOCK neighbors to a
higher value and watch what happens, you'll get the hang of it quickly.

What I don't like about BPQ code is that apparently you can NOT lock a
ROUTE QUALITY to a SPECIFIC NODE *LOWER* than PORT QUALITY  *IF*  the
BPQ node is also hearing it DIRECTLY!  This is a flaw in the code since
it does not allow a sysop to lock one nodes total broadcasts OUT of your
node.  Regular "TheNet and NET/ROM" nodes allow this.

Best of luck.. sorry for the length.. but it's hard to say in a few
words with any real luck of getting the meaning across.

Mark Bitterlich
wa3jpy@wb4uou.#eastnc.nc.usa.noam
mgb@tecnet1.jcte.jcs.mil

------------------------------

Date: 14 Jul 93 18:44:48 GMT
From: news-mail-gateway@ucsd.edu
Subject: MPF102 direct replacement ?
To: packet-radio@ucsd.edu

Hi packeteers ..
Any idea for direct replacement of MPF 102 FET (motorola)
for use in ARRL Handbook(s) projects ?
I will appriciate e-mail answer. (some digests never arrived...)

73 de George (SV3CHA)

------------------------------

Date: Wed, 14 Jul 1993 03:19:38 GMT
From: pravda.sdsc.edu!news.cerf.net!usc!cs.utexas.edu!swrinde!gatech!news-feed-2.peachnet.edu!news-feed-1.peachnet.edu!umn.edu!staff.tc.umn.edu!weiss@network.UCSD.EDU
Subject: NOS and Baycom
To: packet-radio@ucsd.edu

I'm trying to get PA0GRI's NOS (NOSVIEW) running with a Tigertronics Baycom
modem (TCM3105) and a laptop (xt) or 386. NO LUCK. Directories were
unzipped OK with -d option, I THINK I'm set up, and I have been able to at 
least decode AX25 on the laptop. NOTHING on the 386 on com1 OR com2.

Baycom 1.4 works OK, however.

Any ideas? Has anyone got NOS working with a Baycom-type modem? ANy local
contacts I can call?
Thanks,
Jeffrey Weiss N0IRR

------------------------------

Date: 14 Jul 93 14:54:22 GMT
From: news-mail-gateway@ucsd.edu
Subject: Packet-Radio Digest V93 #207
To: packet-radio@ucsd.edu

The gentleman that wanted a name of a Co that produced a TCP/IP pgm
  >>>>> FTP corp. is one.
 
        Go looking for the NCSA code at Clarkson University to FTP Free of
         Charge.
 
        Brad Clemmons is the author.
 
 
 
 
 
      Ken
 
                   >>RVGC2@VTVM1.CC.VT.EDU<<
         >>PHONES 703-857-7584 >>VATECH CAMPUS 13855<<
       >>FAX 703-857-7371<< KEW6X@POE.ACC.VIRGINIA.EDU >>
             >>ARMY MARS AAT3PK/VA<< AMATEUR>N4LYO<<
                     >>IBMMAIL (USVPITMA)<<
                 ROANOKE VALLEY GRADUATE CENTER
                  US SNAIL: 117 W. CHURCH AVE.
                    ROANOKE, VA. 24011-1905

------------------------------

Date: 15 Jul 93 04:17:28 GMT
From: mnemosyne.cs.du.edu!nyx!gbaron@uunet.uu.net
Subject: RTTY DECODING
To: packet-radio@ucsd.edu

dts@banyan.com (Daniel Senie) writes:

>In article <742093147snx@llondel.demon.co.uk>, dave@llondel.demon.co.uk 
David Hough) writes:
>|> In article <742008561.AA05767@csource.oz.au> David.Simpson@f393.n632.
3.fidonet.org (David Simpson) writes:
>|> > I AM USING MFJ1278B WITH IBM 486SX, AND HAVING PROBLEMS DECODING 
>|> > COMMERCIAL RTTY..ANY CLUES PLEASE?
>|> > 
>|> > 
>|> >  * Origin: Spectrum Radio - Melbourne's All Band Radio BBS (3:632/3
3.0)
>|> > 
>|> Are you using the correct tone shift? I think some commercial RTTY us
s 
>|> a 425Hz shift. You also need to check whether it is running 45 or 50b
ud
>|> because that will screw your reception as well. Failing that, it migh
 be
>|> scrambled in some way...
>|> 
>|> Dave

>Amateur RTTY uses 170Hz shift, commercial uses 850 mostly. There are oth
r odd
>shifts in use as well...



>|> 
>|> *********************************************************************
*******
>|> * G4WRW @ GB7WRW.#41.GBR.EU AX25     *    You think *you* have proble
s?    *
>|> * dave@llondel.demon.co.uk  Internet *     What do you do if you *are
      *
>|> * g4wrw@g4wrw.ampr.org      Amprnet  *      a manically depressed rob
t??   *
>|> *********************************************************************
*******

>-- 
>-----------------------------------------------------------------------
>Daniel Senie                 Internet:     dts@questar.banyan.com
>Banyan Systems, Inc.         Compuserve:   74176,1347
>508-898-1188                 Packet Radio: N1JEB@KA1SRD.MA
This is a test post

------------------------------

End of Packet-Radio Digest V93 #208
******************************
